Prior art telecommunication systems allow users to access features on the telecommunication system by dialing a feature-access code that is, sometimes followed by an extension number toward which the feature is to be directed. In stored program controlled telecommunication systems, the individual features are typically implemented via individual software modules, whose execution is invoked by receipt of the corresponding feature-access codes.
In some applications, it is desirable to condition the execution of a feature on factors in addition to the mere dialing of the corresponding feature access code. These factors are generally referred to as the context of the request that the dialing of the access code represents. For example, it may be desirable to deny certain users access to certain features such as being able to make long distance calls. To accomplish this, the prior art conventionally requires that the software of the feature module itself be modified to implement the desired conditionality. The modified software module is then invoked by the mere dialing of the feature-access code, as usual; but instead of automatically providing the called-for feature, the module first checks whether the requisite factors for providing the feature have been satisfied. The module provides the feature only if the factors are found to be satisfied. These factors are stored in tables normally referred to as station or trunk translations. In the above example, the feature module itself accesses and checks the station or trunk translations of the user, who dialed the access code, or the translations of the dialed extension number for permission to invoke the feature.
The feature software modules are a part of the telecommunication system's operating software and are referred to as the feature software. The operating software is a highly-complex set of programs with many intricate interdependencies. Any modifications to the feature software must therefore be done with great care and with an understanding of how those might affect other parts of the operating software or else the telecommunication system may cease to operate properly. Further, these modifications require that the feature modules perform different low level operations such as digit collection which requires a detailed knowledge of the system. Consequently, the introduction of conditionalities into call-feature software, and the customization of those conditionalities, typically cannot be done by the owner of the telecommunication system but must be done by the telecommunication system manufacturer, as a custom development, at a cost of significant effort and expense.
Many telecommunication system owners (e.g., private-party owners of PBXs and public-network owners of central office switches) find this arrangement unsatisfactory. They would like to be able to customize the factors, i.e., the context, that condition the availability or behavior of individual features on individual ones of their telecommunication systems, and to be able to change those factors and their effects at will. For example, a service provider may desire to selectively deny certain features to certain users on one telecommunication system, while selectively disabling those features for all users on a time-of-day basis on another telecommunication system. In addition, a system owner may wish to deny availability of a feature on all systems to all users on the occurrence of conditions that a call has experienced which would make the feature difficult or impossible to use.
Furthermore, a system owner may wish to provide different species of a single generic feature depending upon the context in which the feature is invoked. For example, in response to activation of a call-forwarding feature by a customer service agent, a PBX owner may wish to provide "call forwarding-busy and don't answer" with respect to calls incoming on a customer service line and directed to the agent during the time of day that the agent is on duty, may wish to provide "call-forwarding-don't answer" with respect to calls incoming on the agent's private line during the time of day that the agent is on duty, and may wish to provide "call forwarding-follow me" with respect to calls incoming on the agent's private line during the time of day that the agent is off duty. At the same time, the PBX owner may always wish to deny call-forwarding to the agent's supervisor while the supervisor is on duty and provide the supervisor with "call forwarding-follow me" while the supervisor is off-duty if the supervisor dials a call-forwarding access code. The requirements of this illustrative example are summarized in the following Table A.
TABLE A ______________________________________ Activated Call Forwarding Station time-of-day class-of-service* On duty Off duty ______________________________________ private extension call forwarding- call forwarding- follow me follow me customer service call forwarding- call forwarding- agent busy/don't answer busy/don't answer other agent call forwarding- call forwarding- don't answer follow me agent supervisor not allowed call forwarding- follow me ______________________________________ *The station classof-service is here actually a collection of items of information included in the classof-service definitions that, when taken together, may be said to represent classes as defined in the table.
Due to the way in which feature conditionality is typically implemented in prior art systems, described above, such capabilities are rarely if ever available to system owners today and only if provided by the specific software feature module when it is created.